In general, batch jobs are back office processes executed by a computer system off-line (e.g., not in real time) and non-interactively (e.g., without user interaction). Because batch jobs are typically compute-intensive, they are generally queued or accumulated during peaks hours when computing resources are unavailable or constrained by real-time activities, and are they then executed during non-peak or idle hours when computing resources are available or less constrained. A batch job is generally stored in an input file—often called a batch file, command file or shell script—which is executed by the computer system. The execution of the input file may produce a number of actions as diverse as updating databases, reconciliation of financial transactions, sending emails to users or producing one or more output files to be used by another batch job or a business.
In general, batch jobs run regularly (e.g. daily, weekly, monthly, etcetera). Many batch jobs access databases to get information needed to perform their function. The execution priority order and frequency of queued or accumulated batch jobs is generally managed by a batch scheduler. Generally, an organization or enterprise may execute its own batch jobs using a standalone batch processing computer system or batch server pool that includes plural servers to process the input files (e.g., batch jobs). However, the organization or enterprise that has finite computing resources may wish to outsource the execution of some or all of its batch jobs, or parts thereof, to an organization that has available computing resources to fulfill this need. Therefore, scheduling performed by the batch scheduler may be constrained by a number of factors, including the following factors.
A first factor may be the available capacity in a batch server pool that processes the batch jobs. The available number of servers in the batch server pool may be a limiting factor in executing a large number and/or time-consuming batch jobs.
A second factor may be the service level agreements (SLAs) between the batch job owner and the computing resource owner (e.g., third-party system). SLAs normally specify the frequency of execution of the batch jobs, as well as the start and completion deadlines of such execution. If SLAs are missed, there may be financial impact to the batch job owner and/or customer impact (e.g., batch jobs that are not completed in time).
A third factor may be the availability, load and capacity of the third-party system (e.g., databases, mail servers, and the like) that are needed to execute or complete the processing of batch jobs. It is often the case that the third-party system is shared by other functions (e.g., other departments, other types of load such as real-time traffic, and the like) and is not readily available, e.g., it may only be used at certain times and/or not all their capacity is available.
As a result of the third constraint factor above, it is often simpler to add capacity to the batch server pool than to make capacity and load changes to the third-party system impacted by the batch job. In these cases, batch job scheduling is actually constrained by the third-party.